Subject: Allowing Users to Prefer HPR Routes

From: [email-masked]
Date: Thu, 27 Oct 94 16:14:18 EDT

There has been some discussion raised at the HPR SIG meeting from our
last AIW, and also on this mailing list, regarding the chapter
"Migrating APPN/ISR to APPN/HPR Networks" in the HPR spec.  Some
concerns were raised involving the need to modify the Class of Service
tables using that solution.  So......here is a proposal that performs
the same function - allows network operators to prefer, in a simple
fashion, HPR routes for some of their more critical data traffic -
without requiring any modifications to Class of Service table entries.
In fact, it's probably more convenient for users and about as simple to
implement:

The solution entails adding a new parameter to the NOF DEFINE_MODE
command, called HPR_PREFERRED.  The HPR_PREFERRED parameter indicates
whether HPR routes are preferred when using that mode to establish LU-LU
sessions.  It allows network managers to associate with a mode name a
preference to use HPR routes.  It has the added benefit of allowing HPR
routes to be preferred for any Class of Service associated with that mode
name.

The indicator is passed to TRS as an extra parameter via the REQUEST_ROUTE(RQ)
signal from session services.  If this parameter indicates that HPR
routes are preferred, TRS attempts to build an HPR-only route from
the origin to the destination, giving infinite weight to all ISR-only
TGs.  If an HPR-only route can't be built,
then TRS performs its regular route building for that COS, giving
equal weight to HPR TGs and ISR-only TGs with the same TG
characteristics.

The function to build an HPR-only route is already
incorporated in TRS in order to perform dynamic path switches,
therefore only minor changes need to be made to that component to
add an HPR preference capability.

The DEFINE_MODE command description below shows how HPR preference
is indicated.

DEFINE_MODE
   MODE_NAME(Joe_Mode)
   COS_NAME(#inter)
   HPR_PREFERRED(Y/N)
   . . .
   . . .
   . . .

When the session manager (SM) component sends an INIT_SIGNAL to session
services to initiate a BIND for a new session, the HPR_PREFERRED
indicator is included in the signal.  Session services, in turn,
passes the indicator on to TRS on its REQUEST_ROUTE signal.  TRS is
now able to dynamically build routes that prefer HPR support for some
LU-LU sessions, and build routes that do not prefer HPR support for
other, less critical LU-LU sessions.

End nodes supporting the RTP tower can also indicate to their network
node servers a preference for HPR routes.  An end node indicates
this preference in the Cross-Domain Initiate (X'12C5') GDS
variable that is sent to the NN server to request a route be built
for a newly initiated session.  The Cross-Domain Initiate GDS variable
needs to be modified to allow end nodes to indicate this preference.
The modifications are shown below:

Cross-Domain Initiate (X'12C5') GDS Variable
------------------------------------------------------------------------
Byte    Bit    Content
------------------------------------------------------------------------
0-3            These bytes are defined as in today's APPN
4       0-4    These bits are defined as in today's APPN
        5-6    HPR route indicators:
               00  An HPR route is not preferred for this session
               01  An HPR route is preferred for this session
               10  An HPR route is required for this session (path switch)
               11  Reserved
        7      Reserved
8-n            These bytes are defined as in today's APPN

End nodes that desire their network node server to prefer an HPR route
when initiating a session set the HPR route indicator bits to
B'01'.  If these bits are set to B'00', however, the
network node server can still prefer an HPR route if the mode name
supplied in the CD-Initiate GDS variable is defined at that network
node to prefer HPR routes (i.e. through the DEFINE_MODE command).
This allows operators to define a mode that prefers HPR for all
of the network node's client end nodes with one definition, without
having to manually define that function on every client end node.

---

From: Mark Cossack <[email-masked]>
Date: Fri, 28 Oct 1994 08:59:10 -0500 (CDT)

Maybe this one will make it ...
---------- Forwarded message begins here ----------

Date: Fri, 28 Oct 1994 08:53:49 -0500 (CDT)
From: Mark Cossack <[email-masked]>
Content-Type: X-BE2; 12
To: [email-masked], [email-masked]
Subject: Re: Allowing Users to Prefer HPR Routes

Just as I did not like the original 'prefer HPR route' strategy, I do
not like this one either and it is much for the same reasons.  Just as
the first strategy did, this strategy can force higher utilization of
non-optimal routes.  After all, if the optimal route was HPR only it
would have been chosen without this coercive method.  In addition, this
coercive method can force all your session traffic over one path and
have you lose the load balancing that is possible with alternate routes
of different weights.  You are also requiring system definition
everywhere instead of having the network properly designed in the first
place and I think that is a mistake.

Mark